home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 123 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.4 KB  |  68 lines
  1. Newsgroups: comp.std.c
  2. Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
  3. From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
  4. Subject: Re: ... char * * promotion to char const * const * ...
  5. In-Reply-To: mklenk@updike.sri.com's message of 16 Jan 1996 16:20:42 GMT
  6. Message-ID: <KANZE.96Jan17121659@slsvewt.lts.sel.alcatel.de>
  7. Sender: news@lts.sel.alcatel.de
  8. Organization: SEL
  9. References: <4dgj8q$qin@unix.sri.com>
  10. Date: 17 Jan 1996 11:16:57 GMT
  11.  
  12. In article <4dgj8q$qin@unix.sri.com> mklenk@updike.sri.com (Mark
  13. Klenk) writes:
  14.  
  15. |>     My question is this:
  16.  
  17. |>     Why does a char * * not naturally promote to a
  18. |>     char const * const *?
  19.  
  20. Because the C standard forbids it.
  21.  
  22. |>     The following is legal and generates no compiler
  23. |>     warning:
  24.  
  25. |>         char const * foo;
  26. |>         char *       bar;
  27.  
  28. |>         foo = bar;
  29. |>         // bar = foo;  // Not allowed without cast.
  30.  
  31.  
  32. |>     But why not this:
  33.  
  34. |>         char const * const * foo_array;
  35. |>         char * *             bar_array;
  36.  
  37. |>         foo_array = bar_array;
  38.  
  39. |>     On every compiler I've tried, I get a warning about this,
  40. |>     something like "assignment from incompatible pointer type."
  41.  
  42. As I understand it:
  43.  
  44. Originally, the C standard was going to allow this; in fact, it was
  45. going to allow all casts which added const anywhere in the type.  Then
  46. someone pointed out that the conversion 'char ** -> char *const *' was
  47. unsafe.  As a result, the wording was changed to only allow adding the
  48. const at the top level.
  49.  
  50. During the C++ standardization efforts (much later), Andy Koenig
  51. pointed out that this rule in fact excluded a number of safe casts as
  52. well, and proposed changing it for C++.  A new rule was formulated,
  53. and one of the committee members actually did a mathematical proof
  54. that it allowed all safe casts, and excluded all unsafe ones.  (If
  55. memory serves me right, the rule is not the same for const and for
  56. volatile.)
  57.  
  58. Since the C standardization committee is currently considering a new
  59. version of the standard, perhaps they will also consider adapting the
  60. C++ rules for this case.  (Since it results in a loosening of the
  61. restrictions, no conforming program can be affected.)
  62. --
  63. James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
  64. GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
  65. Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
  66.                 -- A la recherche d'une activitΘ dans une region francophone
  67.  
  68.